home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001176_raisch@ora.com _Mon May 24 19:32:45 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  5KB
  1. Return-Path: <raisch@ora.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA18770; Mon, 24 May 93 19:32:45 MET DST
  4. Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA02251; Mon, 24 May 1993 19:53:54 +0200
  6. Received: by ora.com (5.65c/Spike-2.1)
  7.     id AA16463; Mon, 24 May 1993 13:52:48 -0400
  8. Date: Mon, 24 May 1993 12:40:56 -0400 (EDT)
  9. From: Rob Raisch <raisch@ora.com>
  10. Subject: Re: FYI: Plexus 2.1 is now available 
  11. To: Tony Sanders <sanders@bsdi.com>
  12. Cc: www-talk@nxoc01.cern.ch
  13. In-Reply-To: <9305241522.AA17895@austin.BSDI.COM>
  14. Message-Id: <Pine.3.03.9305241254.E29106-c100000@ruby.ora.com>
  15. Mime-Version: 1.0
  16. Content-Type: TEXT/PLAIN; charset=US-ASCII
  17.  
  18.  
  19.  
  20. On Mon, 24 May 1993, Tony Sanders wrote:
  21.  
  22. > > 1) Kerberos should normally be invisible to users; there should be a
  23. > > TGT whenever the user is logged in.
  24. > Yes, for a single realm.  The problem is that with the Web you are reading
  25. > documents from all over (many possible realms).  Are you going to require
  26. > that the user kinit in a shell window for each document at a different
  27. > site (possibly having to exit the browser each time for line-mode browsers
  28. > with no job control)?
  29.  
  30.     Well, this is the problem.  The solution is not to use something like
  31. Kerberos to authenticate a user to a publisher, since Kerberos does not scale to
  32. the level we are going to need on the Global Internet.
  33.  
  34.     The easy solution is to support the idea of "authentication servers"
  35. where the user is a member or subscriber to an authentication server which is
  36. responsible to identify the particular user to potential publishers.  The
  37. publisher is a subscriber to the same or a different authentication server (and
  38. in this case, we assume that the authentication servers have a trusted method to
  39. share the burden.)
  40.  
  41.     Let me try a real world example:
  42.  
  43.     aUser subscribes to AuthenticationServer-A.        
  44.             (happens only once)
  45.  
  46.     aUser authenticates herself to AuthenticationServer-A via Kerberos.
  47.             (happens once per session)
  48.  
  49.     aUser is now ready to receive documents.
  50.     -----------------------------------------------------
  51.     aPublisher subscribes to AuthenticationServer-B.
  52.             (happens only once)
  53.  
  54.     aPublisher authenticates itself to AuthenticationServer-B.
  55.             (happens when publisher reboots)
  56.  
  57.     aPublisher is now ready for business.
  58.     -----------------------------------------------------
  59.     aUser wishes to retrieve aDocument from aPublisher
  60.  
  61.     aUser requests aDocument from aPublisher
  62.         -- Along with the request goes something along the lines of:
  63.             AuthAgency    AuthMethod    UserCredentials
  64.             ----------    ----------    ---------------
  65.             Server-A    Kerberos        [HOSTNAME] 
  66.                             [USERNAME] 
  67.                             [KERB-TICKET]  (opaque data)
  68.  
  69.             a URA (Uniform Resource Authenticator) might look like:
  70.             Kerberos://Server-A/hostname/username/kerb-ticket
  71.  
  72.     aPublisher checks with AuthenticationServer-B for aUser's credentials
  73.  
  74.     AuthenticationServer-B does not recognize aUser
  75.  
  76.     AuthenticationServer-B contacts AuthenticationServer-A and requests
  77.     credentials for aUser
  78.  
  79.     AuthenticationServer-A returns the proper credentials and...
  80.  
  81.     well, you get the picture....
  82.  
  83.  
  84.     The idea here is that Kerberos by itself is not an authentication
  85. service.  It is a mechanism which can be used to develop such a service.
  86.  
  87.     I would assume that all the AuthenticationServers might use Kerberos to
  88. share info between them, and that all the Users might use Kerberos to
  89. authenticate themselves to the AuthenticationServers.  Of course, there is room
  90. for more and less robust mechanisms as well, depending on the publisher's needs.
  91.  
  92.     There needs to be a major infrastructure of authenticating and authorizing
  93. capabilities on the Internet to support "publishing."  It is not simply a
  94. question of client/server (consumer/producer) because the model does not scale.
  95.  
  96. > > 3) It's bad policy for users to get into the habit of entering their
  97. > > passwords into programs other than passwd, kinit and login.
  98. > I cannot think of any other reasonable solution with the current
  99. > technology (and I'm not interested in rolling my own).
  100.  
  101.     Ahhhh... but I am.  <smile>  O'Reilly is hoping to take a lead here, and
  102. we are actively developing an document which outlines the problems and proposes
  103. a solution.  We are also developing a testbed application, and will ultimately
  104. make this available to other publishers and the network at large.
  105.  
  106.     Anyone interested in particpating, (at this point, in a discussion, but
  107. perhaps in the beta-release), should drop me a line.
  108.  
  109.     </rr>
  110.  
  111.